Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

components/Onboarding/OnboardingContextStep.tsx (1)

23-57: Use a real form for this step.

These fields are collecting submit-able data, but the current div wrapper loses Enter-to-continue and form semantics. Wrapping them in a <form onSubmit={...}> and making the CTA a submit button will improve keyboard flow without adding complexity.

As per coding guidelines, "Use semantic HTML elements appropriate to the component's role" and "Ensure keyboard navigation and focus management in UI components".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingContextStep.tsx` around lines 23 - 57, The
inputs are inside plain divs so Enter-to-continue and form semantics are lost;
wrap the input block in a <form> element and wire its onSubmit to call the
existing onNext handler (use an inline handler that does e.preventDefault() then
calls onNext if needed) so keyboard submit works, then change the CTA Button to
be a submit button (remove the onClick). Keep the existing controlled inputs and
handlers (onChangeName, onChangeCompany) intact so only the wrapper and Button
type/prop change.

components/Onboarding/OnboardingModal.tsx (3)

119-125: ⚠️ Potential issue | 🟠 Major

Add accessible dialog title for screen readers.

The modal lacks an accessible name. Screen reader users won't know what dialog just opened. Per coding guidelines, dialogs require role="dialog" and proper labeling.

♻️ Suggested fix with DialogTitle

+import { Dialog, DialogContent, DialogTitle } from "@/components/ui/dialog";
+
+const STEP_TITLES: Record<Step, string> = {
+  welcome: "Welcome",
+  role: "Select your role",
+  context: "Tell us about yourself",
+  artists: "Add your artists",
+  connections: "Connect your tools",
+  pulse: "Turn on Pulse",
+  tasks: "Your tasks",
+  complete: "You're all set",
+};
+
 <DialogContent
   className="max-w-lg p-0 gap-0 overflow-hidden [&>button]:hidden"
   onInteractOutside={e => e.preventDefault()}
   onEscapeKeyDown={e => e.preventDefault()}
 >
+  <DialogTitle className="sr-only">{STEP_TITLES[step as Step]}</DialogTitle>
   {/* Header */}

As per coding guidelines: "Use role=\"dialog\" and aria-modal=\"true\" for modal/dialog components" and "Provide proper ARIA roles/states."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingModal.tsx` around lines 119 - 125, The Dialog
lacks an accessible name/role for screen readers; update the OnboardingModal to
provide role="dialog" and aria-modal="true" on the dialog container (the Dialog
or DialogContent element) and add a visible or visually-hidden title element
referenced by aria-labelledby (use an existing DialogTitle component or add one
and set its id, then set aria-labelledby to that id) so screen readers announce
the dialog name; ensure onOpenChange handler remains and remove the empty inline
noop if necessary.

---

61-68: ⚠️ Potential issue | 🟠 Major

Artist creation failures are silently ignored.

saveArtist() doesn't throw on HTTP errors — it returns the error response as a resolved promise. The .catch(console.error) only catches network failures, and Promise.allSettled() sees all promises as "fulfilled" regardless of actual success.

Consider checking the response status either in saveArtist or after allSettled:

♻️ Suggested validation

 const artistPromises = (data.artists ?? []).map(a =>
   saveArtist({
     name: a.name,
     spotifyUrl: a.spotifyUrl,
     accountId: userData.account_id,
-  }).catch(console.error),
+  }),
 );
-await Promise.allSettled(artistPromises);
+const results = await Promise.allSettled(artistPromises);
+const failures = results.filter(
+  r => r.status === "rejected" || (r.status === "fulfilled" && r.value?.error)
+);
+if (failures.length > 0) {
+  console.error("Some artists failed to save:", failures);
+}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingModal.tsx` around lines 61 - 68, The artist
creation logic currently swallows server-side failures because saveArtist
returns error responses as resolved promises and the current
.catch(console.error) only handles network errors; update the flow so failures
are detected and handled: either modify saveArtist to throw on non-2xx responses
(so callers can catch) or, after creating artistPromises in OnboardingModal (the
artistPromises array and the await Promise.allSettled(...) call), inspect the
results from Promise.allSettled for any result.status === "fulfilled" whose
value indicates an error response or result.status === "rejected" and
surface/log/propagate those failures (e.g., collect failed artists and show a
user-facing error or retry), ensuring you reference saveArtist and the
artistPromises/Promise.allSettled block when making the change.

---

75-96: ⚠️ Potential issue | 🔴 Critical

Onboarding completion status is not persisted by the API.

Lines 84-94 send onboardingStatus and onboardingData to /api/account/update, but per the API route at app/api/account/update/route.tsx (lines 7-40), these fields are never extracted from the request body or written to the database.

This means userData.onboarding_status remains null, and useOnboarding will reopen the wizard on the next page load — users will be stuck in an infinite onboarding loop.

Fix required in the API route to destructure and persist these fields:

// In app/api/account/update/route.tsx
const { ..., onboardingStatus, onboardingData } = body;

// Then in updateAccountInfo call:
await updateAccountInfo(accountId, {
  ...
  onboarding_status: onboardingStatus,
  onboarding_data: onboardingData,
});

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingModal.tsx` around lines 75 - 96, The API
route handler currently ignores onboardingStatus and onboardingData sent from
the client; update the request body destructuring to include onboardingStatus
and onboardingData (e.g., const { accountId, ..., onboardingStatus,
onboardingData } = body) and pass them into the database update call that uses
updateAccountInfo so the persisted object includes onboarding_status:
onboardingStatus and onboarding_data: onboardingData (ensure you still map other
fields like accountId and existing payloads when calling updateAccountInfo).

components/Onboarding/OnboardingModal.tsx (1)

107-117: Navigation timeout isn't cleaned up on unmount.

The setTimeout on line 115 isn't cleaned up if the component unmounts before it fires. While unlikely in this flow, it's a good practice to clean up all timers:

♻️ Suggested cleanup with ref

+const navigationTimeoutRef = useRef<ReturnType<typeof setTimeout>>();
+
+useEffect(() => {
+  return () => {
+    if (navigationTimeoutRef.current) clearTimeout(navigationTimeoutRef.current);
+  };
+}, []);
+
 const handleComplete = useCallback(async () => {
   await complete();
   const artistNames = (data.artists ?? []).map(a => a.name);
   if (artistNames.length > 0) {
     const q = encodeURIComponent(
       `Give me a complete status report for ${artistNames[0]} — ...`,
     );
-    setTimeout(() => { window.location.href = `/?q=${q}`; }, 200);
+    navigationTimeoutRef.current = setTimeout(() => { window.location.href = `/?q=${q}`; }, 200);
   }
 }, [complete, data.artists]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingModal.tsx` around lines 107 - 117, The
setTimeout started in handleComplete isn't cleared on unmount; store the timer
id in a ref (e.g., timeoutRef) when you call setTimeout in handleComplete (and
clear any existing timeout before assigning), and add a useEffect cleanup that
calls clearTimeout(timeoutRef.current) and nulls it on unmount to prevent the
delayed navigation from firing after the component is unmounted; reference
handleComplete, complete, data.artists and the setTimeout call.

components/Onboarding/OnboardingPulseStep.tsx (1)

38-56: Add keyboard accessibility to the toggle card.

The clickable div acts as a toggle control but lacks keyboard support. Users relying on keyboards or assistive technologies won't be able to interact with it effectively.

Consider adding role="button", tabIndex={0}, and an onKeyDown handler for Enter/Space:

♻️ Suggested improvement

       <div
         className={cn(
           "rounded-xl border-2 p-5 transition-all cursor-pointer",
           enabled
             ? "border-primary bg-primary/8"
             : "border-border bg-muted/20",
         )}
+        role="button"
+        tabIndex={0}
         onClick={() => onToggle(!enabled)}
+        onKeyDown={e => {
+          if (e.key === "Enter" || e.key === " ") {
+            e.preventDefault();
+            onToggle(!enabled);
+          }
+        }}
+        aria-pressed={enabled}
       >

As per coding guidelines: "Ensure keyboard navigation and focus management in UI components" and "Provide proper ARIA roles/states."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingPulseStep.tsx` around lines 38 - 56, The
clickable card wrapping the Switch lacks keyboard/ARIA support; add
role="button", tabIndex={0}, aria-pressed={enabled} and an onKeyDown handler on
the same div that listens for Enter/Space and calls onToggle(!enabled)
(mirroring the onClick behavior and preventing default/propagation as needed),
and ensure the Switch props (checked/onCheckedChange) remain intact so screen
readers get the correct state; use the existing onToggle and enabled symbols to
implement this.

components/Onboarding/OnboardingConnectionsStep.tsx (1)

99-100: Add accessible text for the connected state indicator.

Screen reader users won't know a connector is connected — the CheckCircle2 icon is purely visual. Add visually hidden text:

♻️ Suggested fix

 {isConnected ? (
-  <CheckCircle2 className="h-5 w-5 text-primary shrink-0" />
+  <>
+    <CheckCircle2 className="h-5 w-5 text-primary shrink-0" aria-hidden="true" />
+    <span className="sr-only">Connected</span>
+  </>
 ) : (

As per coding guidelines: "Provide proper ARIA roles/states and test with screen readers."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingConnectionsStep.tsx` around lines 99 - 100,
Add accessible text for the connected state by rendering a visually hidden label
when isConnected is true: keep the CheckCircle2 icon for sighted users but mark
it aria-hidden="true", and add a span (e.g., className="sr-only" or your
project's equivalent) containing an explicit status string like "Connected" next
to the icon inside the OnboardingConnectionsStep component so screen readers
announce the connected state; ensure the text is only present when isConnected
is true and avoid duplicate announcements.

components/Onboarding/useOnboarding.ts (1)

55-61: Consider defensive handling for unexpected onboarding_status shapes.

The type assertion on line 57 assumes onboarding_status is either null or an object with a completed property. If the database contains an unexpected shape (e.g., a string or array), status?.completed could behave unexpectedly.

A more defensive check:

♻️ Suggested improvement

 useEffect(() => {
   if (!userData) return;
-  const status = userData.onboarding_status as Record<string, unknown> | null;
-  if (!status?.completed) {
+  const status = userData.onboarding_status;
+  const isCompleted =
+    typeof status === "object" &&
+    status !== null &&
+    "completed" in status &&
+    status.completed === true;
+  if (!isCompleted) {
     setIsOpen(true);
   }
 }, [userData]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/useOnboarding.ts` around lines 55 - 61, The
onboarding_status property is being asserted to an object and read without
validation; update the useEffect in useOnboarding (the block that reads
userData.onboarding_status and calls setIsOpen) to defensively validate the
shape before checking completed: first guard that userData?.onboarding_status is
an object (typeof === 'object' && not null && !Array.isArray), then narrow it to
a Record<string, unknown> and only read status.completed if that validation
passes; treat non-object shapes (string, array, boolean) as "not completed" or
handle per business rule so you avoid reading undefined properties and
unexpected behavior.

components/Onboarding/OnboardingTasksStep.tsx (1)

64-72: Progressive reveal works but uses mutable closure variable.

The pattern of mutating i inside the interval closure works, but it's a bit unusual. An alternative using functional state update would be more idiomatic:

♻️ Optional refactor

 useEffect(() => {
-  let i = 0;
   const interval = setInterval(() => {
-    setRevealed(prev => [...prev, i]);
-    i++;
-    if (i >= tasks.length) clearInterval(interval);
+    setRevealed(prev => {
+      if (prev.length >= tasks.length) {
+        clearInterval(interval);
+        return prev;
+      }
+      return [...prev, prev.length];
+    });
   }, 180);
   return () => clearInterval(interval);
 }, [tasks.length]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingTasksStep.tsx` around lines 64 - 72, Replace
the mutable closure counter `i` with a functional state-driven update: inside
the effect keep the interval but call `setRevealed(prev => { ... })` to compute
the next index from `prev.length` (so you append the next task index based on
current `revealed` length) and use that same updater to detect when you've
reached `tasks.length` and then call `clearInterval(interval)`; reference the
existing symbols `setRevealed`, `revealed` (via its length), `tasks.length`, and
`clearInterval(interval)` to locate where to implement this change.

components/Onboarding/OnboardingContextStep.tsx (1)

43-55: Consider a guard ref instead of disabling exhaustive-deps.

The effect intentionally runs once to pre-fill the name, but disabling the lint rule hides the implicit contract. A cleaner pattern uses a hasPrefilledRef guard:

♻️ Suggested improvement

+const hasPrefilledRef = useRef(false);
+
 useEffect(() => {
-  if (!name && (userData?.name || email)) {
+  if (hasPrefilledRef.current) return;
+  if (!name && (userData?.name || email)) {
+    hasPrefilledRef.current = true;
     const inferred = /* ... */;
     if (inferred) onChangeName(inferred);
   }
-}, [userData?.name, email]); // eslint-disable-line react-hooks/exhaustive-deps
+}, [name, userData?.name, email, onChangeName]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingContextStep.tsx` around lines 43 - 55,
Replace the disabled exhaustive-deps pattern in the useEffect that pre-fills the
name by adding a persistent guard ref (e.g., hasPrefilledRef) to ensure the
prefill runs only once; update the effect (the useEffect that reads
userData?.name and email and calls onChangeName) to check and set
hasPrefilledRef.current so you can safely include all real dependencies
(userData?.name, email, name, onChangeName) without disabling the lint rule.

components/Onboarding/OnboardingPulseStep.tsx (1)

39-57: Make the toggle card keyboard-accessible.

The card is clickable via mouse but not reachable by keyboard. Since the embedded Switch handles the actual toggle, users can still operate it, but the card's click-to-toggle affordance is mouse-only. Consider adding tabIndex={0}, role="button", and an onKeyDown handler for Enter/Space:

♻️ Suggested improvement

 <div
   className={cn(
     "rounded-xl border-2 p-5 transition-all cursor-pointer",
     enabled ? "border-primary bg-primary/8" : "border-border bg-muted/20",
   )}
   onClick={() => onToggle(!enabled)}
+  onKeyDown={e => { if (e.key === "Enter" || e.key === " ") { e.preventDefault(); onToggle(!enabled); } }}
+  tabIndex={0}
+  role="button"
+  aria-pressed={enabled}
 >

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingPulseStep.tsx` around lines 39 - 57, The card
div in OnboardingPulseStep is only mouse-clickable; make it keyboard-accessible
by adding tabIndex={0}, role="button", and an onKeyDown handler that listens for
Enter and Space and calls onToggle(!enabled) (preventDefault for Space) to
mirror the onClick behavior; ensure the onKeyDown does not interfere with the
inner Switch (keep the Switch's onClick stopPropagation) and update the
accessible attributes so visual focus and screen readers can interact with the
card.

components/Onboarding/OnboardingStepDots.tsx (1)

3-11: Import the canonical OnboardingStep type instead of redefining it.

This local type duplicates OnboardingStep from useOnboarding.ts. If the step list evolves, this copy will drift. Import the shared type to maintain a single source of truth:

♻️ Suggested refactor

+import { type OnboardingStep } from "./useOnboarding";
 import { cn } from "@/lib/utils";

-type OnboardingStep =
-  | "welcome"
-  | "role"
-  | "context"
-  | "artists"
-  | "connections"
-  | "pulse"
-  | "tasks"
-  | "complete";

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingStepDots.tsx` around lines 3 - 11, Remove the
duplicated local OnboardingStep union and instead import the canonical
OnboardingStep from the shared onboarding module (useOnboarding.ts); delete the
local type declaration in OnboardingStepDots.tsx, add an import for
OnboardingStep at the top, and ensure any references in the file (e.g., props,
state, or function signatures that used the local type) use the imported
OnboardingStep type so there’s a single source of truth.

components/Onboarding/OnboardingTasksStep.tsx (1)

65-73: Consider using state for the reveal counter for clearer intent.

The current approach with a mutable i variable works, but mixing mutable closure variables with React state updates can be tricky to reason about. A cleaner pattern uses an interval that increments a counter state:

♻️ Optional refactor

-const [revealed, setRevealed] = useState<number[]>([]);
+const [revealedCount, setRevealedCount] = useState(0);

 useEffect(() => {
-  let i = 0;
   const interval = setInterval(() => {
-    setRevealed(prev => [...prev, i]);
-    i++;
-    if (i >= tasks.length) clearInterval(interval);
+    setRevealedCount(prev => {
+      if (prev >= tasks.length) {
+        clearInterval(interval);
+        return prev;
+      }
+      return prev + 1;
+    });
   }, 180);
   return () => clearInterval(interval);
 }, [tasks.length]);

-// In render: revealed.includes(i)
+// In render: i < revealedCount

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingTasksStep.tsx` around lines 65 - 73, Replace
the mutable closure counter with React state: create a reveal counter state
(e.g., revealIndex via useState) and update it inside the useEffect interval
instead of using the local variable i; in the same effect increment revealIndex
with setRevealIndex(prev => prev + 1) on each tick, push the new index into
setRevealed (or derive revealed from revealIndex) and clear the interval when
revealIndex >= tasks.length or on cleanup. Update references in the component to
use revealIndex and ensure the effect depends on tasks.length and revealIndex
(or only tasks.length if deriving revealed inside the effect) so the interval
logic in useEffect, setRevealed, and the cleanup are deterministic and avoid
closure-stale values.

components/Onboarding/useOnboarding.ts (1)

55-61: Consider stricter type validation for onboarding_status.

The database schema shows onboarding_status is typed as Json | null, which can be any JSON value—strings, numbers, booleans, arrays, or objects. The current type assertion to Record<string, unknown> doesn't guard against non-object values.

If onboarding_status were set to a string, number, or array, the check !status?.completed would still evaluate to true (since those types don't have a completed property), potentially opening the modal unintentionally.

♻️ Proposed type guard for safer validation

 useEffect(() => {
   if (!userData) return;
-  const status = userData.onboarding_status as Record<string, unknown> | null;
-  if (!status?.completed) {
+  const status = userData.onboarding_status;
+  const isCompleted =
+    typeof status === "object" &&
+    status !== null &&
+    !Array.isArray(status) &&
+    "completed" in status &&
+    status.completed === true;
+  if (!isCompleted) {
     setIsOpen(true);
   }
 }, [userData]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/useOnboarding.ts` around lines 55 - 61, The current
cast of userData.onboarding_status to Record<string, unknown> is unsafe; update
the useEffect to perform a runtime type guard on onboarding_status (check it is
non-null, typeof === 'object', not an array) and then verify the completed
property exists and is a boolean (e.g., 'completed' in status && typeof
status.completed === 'boolean') before deciding to call setIsOpen(true); locate
the useEffect that reads userData and replace the direct cast with this guard so
non-object JSON (string/number/array) won't incorrectly open the modal.

components/Onboarding/OnboardingNavButtons.tsx (1)

21-24: Set explicit button types on these reusable actions.

Native buttons default to submit, so this nav row can trigger accidental form submissions if a later step wraps its content in a <form>. Setting type="button" here keeps the component safe to reuse.

Suggested change

-      <Button variant="outline" onClick={onBack} className="w-24">
+      <Button type="button" variant="outline" onClick={onBack} className="w-24">
         ← Back
       </Button>
-      <Button onClick={onNext} disabled={nextDisabled} className="flex-1">
+      <Button type="button" onClick={onNext} disabled={nextDisabled} className="flex-1">
         {nextLabel}
       </Button>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingNavButtons.tsx` around lines 21 - 24, The
Back and Next buttons (Button components using onBack and onNext with prop
nextDisabled) lack explicit type attributes and will default to type="submit",
risking accidental form submissions; update the Button instances for the Back
(onBack) and Next (onNext) actions to include type="button" so they behave as
non-submitting nav controls while preserving existing props like variant,
disabled and className.

components/Onboarding/onboardingRoleConfig.ts (1)

70-80: Reuse the canonical "other" config in the fallback.

This duplicates data that already exists in ONBOARDING_ROLES, so the two definitions can drift. Returning ROLE_CONFIG_MAP.other keeps the fallback aligned with the source of truth.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/onboardingRoleConfig.ts` around lines 70 - 80, The
fallback in getRoleConfig currently returns a hard-coded "other" object that
duplicates ONBOARDING_ROLES; change it to return the canonical entry from
ROLE_CONFIG_MAP instead (i.e., use ROLE_CONFIG_MAP["other"] or
ROLE_CONFIG_MAP.other) so the fallback stays in sync with the source of truth;
update getRoleConfig to return ROLE_CONFIG_MAP[roleId ?? ""] ??
ROLE_CONFIG_MAP.other and remove the duplicated literal object.

components/Onboarding/OnboardingArtistsStep.tsx (3)

128-134: ⚠️ Potential issue | 🟠 Major

Give the remove button an accessible name.

The icon-only control still exposes just button to assistive tech. Add an aria-label that includes the artist name.

As per coding guidelines, "Provide proper ARIA roles/states and test with screen readers".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingArtistsStep.tsx` around lines 128 - 134, The
remove button is icon-only and lacks an accessible name; update the button in
OnboardingArtistsStep (the button that calls remove(i) and renders <X />) to
include an aria-label that includes the artist's name (e.g., "Remove
{artist.name}") so screen readers get a meaningful label; ensure you use the
current item variable (the artist object from the array/map for index i) to
build the string and keep the visual markup unchanged.

---

33-49: ⚠️ Potential issue | 🟡 Minor

Use one duplicate check for both add paths.

addFromSpotify() only de-dupes by Spotify URL while addManual() only de-dupes by normalized name, so the same artist can still be added twice and later saved twice. Reuse a single predicate before either path mutates artists.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingArtistsStep.tsx` around lines 33 - 49, The
duplicate-check logic is inconsistent: addFromSpotify (function addFromSpotify)
only checks spotifyUrl while addManual (function addManual) only checks
normalized name, allowing duplicates; refactor by creating a single predicate
(e.g., isDuplicate) that takes either a SpotifyArtist or a name and returns true
if artists contains an entry with the same normalized name or matching
spotifyUrl, then call this predicate from both addFromSpotify and addManual
before calling onUpdate/clearResults to prevent any duplicate insertions into
artists.

---

72-111: ⚠️ Potential issue | 🟠 Major

This search is still mouse-first.

The input/results pair still has no programmatic label, aria-expanded/aria-controls/aria-activedescendant, or arrow-key traversal, and both option buttons use onMouseDown, so Enter/Space on a focused option will not select it. Please wire this up as a real combobox/listbox interaction.

As per coding guidelines, "Ensure keyboard navigation and focus management in UI components" and "Provide proper ARIA roles/states and test with screen readers".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingArtistsStep.tsx` around lines 72 - 111, The
combobox is currently mouse-first; in OnboardingArtistsStep add proper ARIA and
keyboard handling by giving the Input an id and role="combobox" plus
aria-expanded and aria-controls pointing to the dropdown id, track an
activeIndex state and set aria-activedescendant to the focused option id when
showDropdown/showManualAdd is true, implement onKeyDown on the Input to handle
ArrowDown/ArrowUp to move activeIndex and Enter/Space to call
addFromSpotify(results[activeIndex]) or addManual, change the option elements in
the dropdown (rendered by ArtistSearchResult and the manual button) to have
role="option", unique ids, highlight based on activeIndex, and use onClick (and
also handle onKeyDown for Enter/Space) instead of onMouseDown so keyboard
selection and screen readers work correctly while keeping existing
addFromSpotify/addManual handlers.

components/Onboarding/OnboardingModal.tsx (1)

48-53: ⚠️ Potential issue | 🟠 Major

Give the dialog an accessible title.

DialogContent still opens without an accessible name, so screen readers will not announce what modal just appeared. Add a DialogTitle/aria-labelledby that tracks the current step, including the welcome and complete states.

As per coding guidelines, "Provide proper ARIA roles/states and test with screen readers".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingModal.tsx` around lines 48 - 53, The modal
currently opens without an accessible name; add a DialogTitle (or set
aria-labelledby on DialogContent) that updates to reflect the current onboarding
step (including the welcome and complete states) so screen readers announce the
modal; update the component that renders DialogContent (the DialogContent
element) to include a DialogTitle element (or an id referenced by
aria-labelledby) that is derived from the step state/variable that drives the
content (e.g., the same state used for welcome/complete) and ensure the title
text changes with the step.

components/Onboarding/OnboardingTasksStep.tsx (1)

7-8: Tie roleType to the shared onboarding role ids.

roleType: string | undefined plus Record<string, ...> means a typo or rename in components/Onboarding/onboardingRoleConfig.ts:15-64 quietly falls through to the default tasks on Line 62. Derive the role-id union from the shared config so this drift is caught at compile time.

Also applies to: 50-55, 61-62

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@components/Onboarding/OnboardingTasksStep.tsx` around lines 7 - 8, Change the
loose string types to a compile-time linked role-id union: replace RoleTaskMap's
key type (currently Record<string, ...>) with a union derived from the shared
onboarding config (e.g. keyof typeof onboardingRoleConfig or an exported
OnboardingRoleId type) and update the roleType variable to that same union
(roleType: OnboardingRoleId | undefined). Import or derive the union from
components/Onboarding/onboardingRoleConfig (use keyof typeof
onboardingRoleConfig if no explicit type is exported) so any rename/typo in the
shared config fails to compile instead of falling back to defaults; update all
related usages (RoleTaskMap, the roleType declaration, and the lookup that falls
back to default tasks) to use the new union type.